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REMARKS 

Reconsideration and allowance of the present application are respectfully 
requested. Claims 1-35 remain pending in the application. By this Amendment, the 
title of invention is amended, and a second mark-up of patent specification is 
provided under 37 C.F.R. §1.105. No new matter is added. 

L Summary of August 3 Election to June 11 Restriction Requirement 
In the earlier June 1 1 Office Action, the Examiner required a restriction among 
two (2) groups of claims as follows: 

Group I: Claims 1-18, 34 and 35, drawn to a method related to 
providing a Certificate Status Service; and 

Group II: Claims 19-33, drawn to a method related to executing a 
transaction by transferring control of an authenticated information object having a 
verifiable evidence trail. 

In Applicants 1 Response to a Restriction Requirement of August 3, 2007, 
Applicants elected Group I (corresponding to claims 1-18, 34 and 35, and drawn to a 
method related to providing a Certificate Status Service), with traverse. 

II. November 2 Supplemental Reg, for Information Under 37 CFR 1.105 
This Amendment is in response to the Supplemental Requirement for 
information under 37 CFR 1.105 set forth in the November 2, 2007 Office 
Communication. The Examiner has on page 2 of the November 2 Office 
Communication set forth a supplemental requirement for information under 37 C.F.R. 
§1.105. Specifically, in numbered paragraph 1, page 2 of the Office Communication, 
the Examiner acknowledges receipt of "the mark-up of the present specification" 
showing subject matter added or changed from provisional application Serial No. 
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60/397,178, but "notes that there are also portions of text that are shown in boldface 

and it is not clear what this is intended to represent." In response to this 
requirement as set forth in paragraphs 1 and 2 by the Examiner, Applicants herewith 
provide a second mark-up of the present specification showing the subject matter 
added or changed from Provisional Application Serial No. 60/397,178 that was filed 
on July 18, 2002. 

A. Second Mark-Up of Present Specification of Serial Number 10/620,817 in 
Relation to Provisional Application Serial Number 60/397,178, filed July 18, 2002 

In response to the November 2 supplemental requirement for information 

under 37 CFR 1.105, Applicants provide the following reply with candor and good 

faith under 37 CFR 1 .56. A second mark-up of the present specification is attached 

herewith showing the textual changes between the last Provisional Application filed 

July 18, 2002 (Ser. No. 60/397,178) and the present utility application. In 

compliance with the Examiner's noted comments in paragraphsl and 2 of the 

November 2 Office Communication, texts deleted in the present application are 

shown with a strike-out, and texts that are added in the present application are 

shown with an underline. All extraneous representations are removed per 

Examiner's comments. 

B. Elected Claims (Group I) of Patent Application Serial Number 10/620,817 
Related In Priority Only To Provisional Application Serial Number 60/397,178, As 
Claimed Under 35 U.S.C. §1 19(e) 

In paragraph 3 of the November 2 Office Communication, the Examiner 

recites the application history of related matters as listed in the domestic priority 

data. Applicants respectfully would like to direct the Examiner's attention to the 

elected claims of Patent Application Serial Number 10/620,817, which only have 
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priority to Provisional Application Serial Number 60/397,178 filed 07/18/2002, and 
claimed under 35 U.S.C. §1 19(e). That is, the previously elected Claim Group I: 
claims 1-18, 34 and 35, only have priority to the provisional application filed 
07/18/2002, as they describe a Certificate Status Service (CSS) capable of 
interoperating concurrently with a multitude of approved PKI and or standalone CA. 

However, regarding the non-elected Claim Group II; claims 19-33, the priority 
extends to the Applicants 1 listed priority data of record. This second group of non- 
elected claims extends the capability of applicants' prior inventions (of the application 
priority data) by describing use of a CSS that enables the trusted repository to work 
concurrently and ubiquitously with a multitude of client approved PKI and or 
standalone CAs. 

Accordingly, as for the elected claims (Group I), the relevant priority among 
the priority information of record is based on Provisional Application Serial Number 
60/397,178, filed 07/18/2002, and claimed under 35 U.S.C. §1 19(e). 

Applicants respectfully submit that the information being provided is in 
Applicants' best compliance with the supplemental requirement for information set 
forth in the Examiner's November 2 Office Communication. Accordingly, Applicants 
respectfully submit that the below summarized remarks, together with the attached 
second specification mark-up, comprise complete Applicants' response to the 
Examiner's supplemental requirement for information under 37 CFR 1.105. 

C. Summarized Remarks Pertaining To The Grouped Claims 

The application as submitted described a CSS (Group I claims) and its 
utilization by prior applicant inventions (Group II claims) to fulfill the requirement that 
all digital signatures applied to any electronic original information object must be 
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valid at the time that they are submitted to a trusted repository. All prior related 
inventions require that the trusted repository check the status of the authentication 
certificates associated with any digital signature attached to submitted electronic 
original information objects that may also be authoritative copies. If the 
authentication certificate status is expired or revoked, than the subscriber is required 
to request, receive and apply a new authentication certificate from a CSS approved 
CA, before they will be able resubmit the digitally signed electronic original 
information object. 

When the eOriginal trusted repository was implemented for commercial use it 
became quickly apparent that certificate status checking requirement was more 
computational demanding, and fraught with added communication and 
interoperability complexity than first thought. Many customer and subscriber 
organizations had preexisting relationships with a large number of different PKIs and 
CAs that also supported dissimilar certificate status reporting means and trust levels. 
So as not to have to turn business away eOriginal had to create a means to solve 
the processing, interoperability, communications and trust issues resulting when 
interworking with multiple PKIs and CAs. 

In this Applicants' invention the CSS works to concurrently retrieve required 
certificate status from a multitude of approved certificate issuers. It performs a 
function comparable to a check clearing house, in that it is able to identify the issuing 
CA, and if it is found on the approved list, route the status request, retrieve and 
cache status, and return actual certificate status to the requesting entity. If the 
issuing CA is not found on the approved list, the CSS always returns an invalid 
certificate status. This retrieve current status requirement is even more crucial with 
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introduction of eOriginal's newest product, eCore On Demand (EOD). EOD is 
intended to allow any client company to sign-up to use this service without undo 
setup constraints and then rapidly ramp up usage. By using the CSS eOriginal is 
able to transparently satisfy all client certificate status checking requirements, 
whether they relate to the 1st or nth information object to be authenticated by the 
trusted repository. Without a CSS eOriginal would have had to require its clients to 
establish PKI/CA trust relationships or employ other trust building means. Therefore, 
without a CSS it would have been impractical to even think about offering EOD. 
Commerce between clients (i.e., primary and secondary financial markets) would 
have been restricted and costly, if allowed at all. The CSS when employed by EOD 
makes these and other types of transactions both practical and affordable. 
D. Independent Claims of Elected Group I: Claims 1,11 and 15 
On page 4 of the November 2 Office Communication, the Examiner asks 
"More specifically, for each of independent Claims 1,11 and 15, Applicant is required 
to answer: which portions of the disclosure of the present application, and which 
portions, if any, of the disclosures of each of the above parent applications, provide 
the written description and enablement support, as per 35 U.S.C. 112, first 
paragraph, for each of the independent claim elements?" 

Regarding the previously elected Claim Group I, as set forth above, 
independent claims 1,11 and 15, only have priority to Provisional Application 
60/397,178 filed 07/18/2002, as they describe a Certificate Status Service (CSS) 
capable of interoperating concurrently with a multitude of approved PKI and or 
standalone CA. Support for the respective independent claim can be found in Non- 
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Provisional Application Ser. No. 10/620,817 as referenced to the specification filed 
July 16, 2003 below. 

Claim 1 recites a method of providing a Certificate Status Service ("CSS") for 
checking validities of authentication certificates issued by respective issuing 
Certification Authorities ("CAs") (e.g., page 8, lines 27-28), comprising the steps of: 
identifying information needed for retrieving a status of an authentication certificate 
from an issuing CA that issued the authentication certificate (e.g., page 8, lines 29- 
30); configuring a connector based on the identified information for communicating 
with the issuing CA (e.g., page 8, lines 30-31); communicating with the issuing CA 
according to the configured connector when the status of the authentication 
certificate is queried (e.g., page 8, lines 31-32); and retrieving the status of the 
authentication certificate (e.g., page 8, line 32 through page 9, line 1); wherein the 
issuing CA and the connector are designated on a list of approved CAs in a 
configuration store (e.g., page 9, lines 1-2). Figure 1, found on page 47; and the 
CSS certificate status query and resulting actions represented on page 18, line 32 
through page 21, line 5 provide a more detailed description of an exemplary 
embodiment of this invention. 

Claim 1 1 recites a method of retrieving a status of an authentication certificate 
issued by an issuing Certification Authority ("CA") in response to a query from a 
trusted third-party repository of information objects to a Certificate Status Service 
("CSS") to validate the authentication certificate's status (e.g., page 10, lines 5-7), 
comprising the steps of: locating and reporting the status if the status is present and 
current in a cache memory of the CSS (e.g., page 10, lines 7-9); otherwise 
performing the steps of: obtaining a status type and retrieval method from a CSS 
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configuration store (e.g., page 10, lines 9-10); if the status type is Certificate 
Revocation List ("CRL") and the last retrieved CRL is current, but the status is not 
found in the cache memory, then reporting the status as valid (e.g., page 10, lines 
10-11); if the status type is not CRL, then composing a certificate status request 
according to the status type (e.g., page 10, lines 1 1-12); establishing a 
communication session with the issuing CA (e.g., page 10, line 13); retrieving the 
status from a status reporting component of the issuing CA using the obtained 
retrieval method and ending the communication session (e.g., page 10, lines 13-15); 
interpreting the retrieved status (e.g., page 10, line 15); associating, with the 
interpreted retrieved status, a time-to-live value representing a period specified by a 
CSS policy for the status type (e.g., page 10, lines 15-17); adding at least the 
authentication certificate's identification, status, and time-to-live values to the cache 
memory (e.g., page 10, lines 17-18); and reporting the status to the trusted third- 
party repository of information objects in response to the query (e.g., page 10, lines 
18-19). Figure 2, found on page 48; and the CSS handling of CRL retrieval and 
parsing represented on page 21, lines 6-26 provide a more detailed description 
exemplifying how the CSS utilizes CRLs and delta CRLs to determine certificate 
status for those PKIs and CAs that use this means of reporting certificate status. 

Claim 15 recites a Certificate Status Service ("CSS") for providing accurate 
and timely status indications of aqthej^cation certificates issued by issuing 
Certification Authorities ("CAs") (e.g., page 10, lines 20-21), comprising: providing a 
status of an authentication certificate as indicated by a Certificate Revocation List 
("CRL") when the certificate's issuing CA uses CRLs for indicating status (e.g., page 
10, lines 22-23); otherwise, providing the status indicated by a cache memory when 
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the cache memory includes a status and a time-to-live data element is not exceeded 

(e.g., page 10, lines 24-25); if the time-to-live data element is exceeded, clearing the 

status from the cache memory (e.g., page 10, lines 25-26); requesting and retrieving 

the status using a real-time certificate status reporting protocol when the status is not 

in the cache memory (e.g., page 10, lines 26-28); adding at least the certificate's 

identification, status, and time-to-live data element to the cache memory (e.g., page 

10, lines 28-29); and providing the retrieved status (e.g., page 10, line 29). Figure 1, 

found on page 47; and the CSS certificate status query and resulting actions 

represented on page 18, line 32 through page 21, line 5 provide a more detailed 

description of an exemplary embodiment of this invention. 

The specific enabling description of the above referenced claim features is 
further supported by the "Detailed Description' 1 in general, and as shown in Figures 
1-8. 

E. The Claims of Elected Group I: Claims 1-18, 34 and 35 
On page 4 of the November 2 Office Communication, the Examiner asks 
"which portions of the disclosure of the present application, and which portions, if 
any, of the disclosures of each of the above parent applications, provide the written 
description and enablement support, as per 35 U.S.C. 112, first paragraph, for each 
of the dependent claim elements?" 

Regarding the previously elected Claim Group I, as set forth above, 
dependent claims 2-10, 12-14, 16-18, 34 and 35, only have priority to Provisional 
Application 60/397,178 filed 07/18/2002, as they describe a Certificate Status 
Service (CSS) capable of interoperating concurrently with a multitude of approved 
PKI and or standalone CA. 



Attorney's Docket No. 1003670-000104 
Application No. 10/620,817 
Page 1 1 

For clarity, support for the entirety of the elected Group I claims can be found 
in Non-Provisional Application Ser. No. 10/620,817 as generally referenced to the 
specification filed July 16, 2003 below. 

Claim 1: Support in Ser. No. 10/620,817, e.g., page 8, line 37 - page 9, line 2; 
page 18, line 32 through page 21, line 5; and Fig. 1. 

Claim 2: Support in Ser. No. 10/620,817, e.g., page 9, lines 3-4. 

Claim 3: Support in Ser. No. 10/620,817, e.g., page 9, lines 4-7. 

Claim 4: Support in Ser. No. 10/620,817, e.g., page 9, lines 8-12. 

Claim 5: Support in Ser. No. 10/620,817, e.g., page 9, lines 14-23. 

Claim 6: Support in Ser. No. 10/620,817, e.g., page 9, lines 24-29. 

Claim 7: Support in Ser. No. 10/620,817, e.g., pg. 9, line 30 - pg. 10, line 4. 

Claim 8: Support in Ser. No. 10/620,817, e.g., pg. 13, lines 27-33; pg. 17, 
lines 14 - 20; and pg. 25, line 30 - pg. 26, line 2. 

Claim 9: Support in Ser. No. 10/620,817, e.g., page 25, line 30 - pg. 26, line 2. 

Claim 10: Support in Ser. No. 10/620,817, e.g., page 28, lines 10-12. 

Claim 11: Support in Ser. No. 10/620,817, e.g., page 10, lines 5-19; page 21, 
lines 6-26; and Fig. 2. 

Claim 12: Support in Ser. No. 10/620,817, e.g., page 12, lines 28-29. 

Claim 13: Support in Ser. No. 10/620,817, e.g., page 19, lines 18-21. 

Claim 14: Support in Ser. No. 10/620,817, e.g., page 28, lines 10-12. 

Claim 15: Support in Ser. No. 10/620,817, e.g., page 10, lines 20-29; page 18, 
line 32 through page 21, line 5; and Fig. 1. 

Claim 16: Support in Ser. No. 10/620,817, e.g., page 10, lines 30-34. 

Claim 17: Support in Ser. No. 10/620,817, e.g., page 11, lines 1-4. 
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Claim 18: Support in Ser. No. 10/620,817, e.g., page 11, lines 4-8. 

Claim 34: Ser. No. 10/620,817, e.g., pg. 10, Ins. 25-28 and pg. 34, Ins 7-8. 

Claim 35: Support in Ser. No. 10/620,817, e.g., page 35, lines 3-10. 

The specific enabling description of the above referenced claim features is 
further supported by the "Detailed Description" found in Non-Provisional Application 
Ser. No. 10/620,817 in general, and as shown in Figures 1-8. 

Likewise, for clarity, support for the elected Group I claims as best can be 
found in Provisional Application Ser. No. 60/397,178 are generally referenced to the 
specification filed July 18, 2002 below. 

Claim 1: Support in Ser. No. 60/397,178, e.g., page 11, Iines1-19; page 16, 
line 22 through page 18, line 29. (See, also, claim 1 and Fig. 1 in the Provisional 
Application). 

Claim 2: Support in Ser. No. 60/397,178, e.g., page 12, lines 21-26. 

Claim 3: Support in Ser. No. 60/397,178, e.g., page 8, lines 5-16 (See, also, 
claim 1 in the Provisional Application). 

Claim 4: Support in Ser. No. 60/397,178, e.g., page 16, lines 2-13. 

Claim 5: Support in Ser. No. 60/397,178, e.g., page 16, lines 2-13 (See, also, 
claim 23 in the Provisional Application). 

Claim 6: Support in Ser. No. 60/397,178, e.g., page 19, lines 12-19. 

Claim 7: Support in Ser. No. 60/397,178, e.g., pg. 19, lines 5-11. 

Claim 8: Support in Ser. No. 60/397,178, e.g., pg. 11, lines 6-12 and pg. 15, 
lines 1-7. 

Claim 9: n/a or tbd 

Claim 10: n/a or tbd 
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Claim 11: Support in Ser. No. 60/397,178, e.g., page 18, line 30 through page 
19, line 19. (See, also claim 17 and Fig. 2 in the Provisional Application.) 

Claim 12: Support in Ser. No. 60/397,178, e.g., page 30, lines 26-28 (see, 
claim 22 in the Provisional Application). 

Claim 13: Support in Ser. No. 60/397,178, e.g., page 17, lines 10-16. 

Claim 14: n/a or tbd 

Claim 15: Support in Ser. No. 60/397,178, e.g., page 16, line 22 through page 
18, line 29. (See, also, claim 22 and Fig. 1 in the Provisional Application.) 

Claim 16: Support in Ser. No. 60/397,178, e.g., see, claim 23 in the 
Provisional Application. 

Claim 17: Support in Ser. No. 60/397,178, e.g., see, claim 24 in the 
Provisional Application. 

Claim 18: Support in Ser. No. 60/397,178, e.g., see, claim 26 in the 
Provisional Application. 

Claim 34: n/a or tbd 

Claim 35: n/a or tbd 

The specific enabling description of the above referenced claim features is 
further supported by the "Detailed Description" found in Provisional Application Ser. 
No. 60/397,178 in general, and as shown in Figures 1-7. The above noted 
exceptions are specially commented below. 

An explanation as to claims 9, 10, 14, 34 & 35 

There was an added disclosure in the non-provisional application with respect 
to pending claims 9, 10, 34 & 35. See, above specification references. 

Claim 9 and 34 are examples of providing a means to reduce computation 
and communications overhead during period of low CSS utilization. Claim 9 is 
intended to provide the means to refresh the status for several certificates in one 
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communication session with the same subject issuing CA where the certificate status 
use-counters are exceeded. The use-counter indicates that there has been much 
activity performed by the holders of these certificates. Claim 34 frees up CSS cache 
for stale certificate statuses where the time-to-live data element is exceeded. There 
is no reference to either in the provisional application. 

Claim 10: Certificate use is in global commerce and communications is 
expanding. Certificates support secure socket layer (SSL) encryption, media 
encryption, file encryption, code signing, S/MIME, digital signatures, and many other 
applications. Some applications, anonymous transactions, do not involve issued 
party specific identification. Claim 10 anticipates use of the CSS to check certificate 
status for such anonymous transactions. See, also, claim 14. 

Claim 35: The CSS is intended to work with any PKI, CA, or other certificate 
status reporting means. Since a CSS is itself a certificate status reporting means, 
Claim 35, enables the CSS to utilize another CSS as the source of certificate status 
as long as that CSS has a connector and is specified in the approved list. 
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111. Conclusion 

Applicants earnestly solicit favorable consideration of the above response and 
early passage to issue the present application. The Examiner is invited to contact 
the undersigned at the below-listed telephone number, if it is believed that 
prosecution of this application may be assisted thereby. 



Respectfully submitted, 



Buchanan Ingersoll & Rooney pc 



Date: December 31, 2007 




Richard J. Kim 
Registration No. 48360 
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SYSTEM AND METHOD FOR ELECTRONIC TRANSMISSION, 

STORAGE AND RETRIEVAL OF AUTHENTICATED DOCUMENTS 



This application is a continuation-in-part of U.S. Patent Application No. 
09/737.325 filed on December 14. 2000. which is a continuation of International 
Application No. PCT/US 00/32 746. filed on December 1 2000 that designates 
the United States and a continuation-in-part of U.S. Patent Application No. 
09/452.928. filed on December 2. 1999 now U.S. Patent No. 6.367.013. which is 
a continuation-in-part of U.S. Patent Application No. 09/072.079 filed on Mav 4. 
1998. now U.S. Patent No. 6.237.096. which is a continuation-in-part of U.S. 
Patent Application No. 08/528.841 filed September 15. 1995. now U.S. Patent 
No. 5.748.738. which is a continuation-in-part of U.S. Patent Application No. 
08/373,944 filed January 17, 1995, now U.S. Patent No. 5.615,268, all by Bisbee 
et al. This a p plication claims priority to the filing date of U.S. Provisional Patent 
Application No. 60/397,178 that was filed on July 18, 2002. These patents and 
applications are incorporated in this application bv reference. 
BACKGROUND 

Applicants' invention relates to systems and methods for providing a 
verifiable chain of evidence and security for the creation, execution, 
maintenance, transfer, retrieval and destruction of electronic original information 
objects ^, such as Electronic Original™ documents. 

This invention e xpands onadvantaqeously uses Applicants' Trusted 
Custodial Utility that holds electronic original records and comparable system 
roles as a virtual electronic vault in validating the right of an individual to perform 
a requisite action, the authenticity of submitted electronic information objects, 
and the status of the authentication certificates used in the digital signature 
verification and user authentication processes. Such TCUs and operations are 
described in U.S. Patents No. 5,615,268; No. 5,748,738; No. 6,237,096; and No. 
6367.013. 

The following list of acronyms abbreviations is used in this description: 
Acronyms 



B2B Busin e ss to Bus i ness 

B2Q Busin e ss - to - Consum e r 
Abbreviations 

CA Certification Authority 

GJP Continuation i n part 

GP Certificate Policy 

CRL Certificate Revocation List 

CSS Certificate Status Service 

HTML Hypertext Markup Language 



ID Identification 



IETF 
ITU 



Internet Engineering Task Force 
International Telecommunications Union 



LDAP Lightweight Directory Access Protocol 

OCSP Online Certificate Status Protocol, IETF-RFC 2560 X.509 

Internet Public Key Infrastructure Online Certificate Status Protocol 
-OCSP, June 1999. 

PIN Personal Identification Number 

PKCS Public-Key Cryptographic Standards 

PKI Public Key Infrastructure 

PKIX Public Key Infrastructure (X.509) 

RA R e g i stration Authority 

RSA Riv e st Shamir Adl e man (publ i c k e y algorithm & company) 

S/MIME Secure Multi-Purpose Internet Mail Extensions 

SCVP Simple Certificate Validation Protocol, Draft-IETF-PKIX- 

SCVP-06, July 2000 
SHA 1 S e cur e Hash Algor i thm Revision 1 

SSL Secure Socket Layer 

TCU Trusted Custodial Utility 

UETA Uniform Electronic Transactions Act 

URi Uniform Rosourco I dentifi e r 

URL Un i form R e sourc e Locator 

XML Extensible Markup Language 

The U.S. Electronic Signatures in Global and National Commerce Act 
(-ESIGN-) legislation and U.S. state laws modeled after the Uniform El e ctronic 
Transactions Act ("UETA'^j iEIA drafted by the National Conference of 
Commissioners on Uniform State Laws and approved and recommended for 
enactment in 1999 provide c e rtain assurances of legal standing for electronically 
signed information objects (electronic documents) which has generated 
government, banking and electronic commerce activity aimed at realizing the 
efficiency and economies of these potentially wholly electronic transactions. 

Pub li c K e y I nfrastructur e ( PKI) and the C e rt i ficat i on Authority (CA) CA are 

the b e droc k base elements of digital signature technology used in creating 
electronic source records. A PKI is a collection of CAs where trust is established 
between users and user organizations by creating either a hierarchical 
relationship between CAs or through cross-certification amongst cooperating 
CAs. A CA is empowered to issue authentication certificates that bind an 
individual's or entity's identity to his or its public key (verifying), where only the 
individual is given access to the matching private key (signing). At the time of 



this application^, certificates normally conform to the Internat i ona l 
Te l ecommunicat i ons Union ( I TU)J TLL X.509 certificate standard and are 
themselves digitally signed by the issuing CA. Such certif icates are depicted in 
FIG. 10 of U.S. Patent No. 6.237 096 for example, that is cited and incorporated 
above. These authentication certificates contain a serial number, identifying 
information of the subject (user) and issuer (CA), the certificate's validity period 
(date and time before and after which it may not be used), the subj e cts subject's 
public key, and cryptographic algorithm information needed to create and verify 
digital signatures. 

To create a digital signature^ an information object is hashed (processed 
using a one-way cryptographic function that can detect as little as a one bit 
alteration in the object) and the hash is then encrypted using the individual's 
private (secret) key. Digital signature verification is achieved by reversing this 
process. The digital signature is decrypted using the individual's public key 
retrieved from their authentication certificate and the result is compared to a re- 
hash of the original information object. These processes may vary when using 
different digital signature algorithms. Digital signatures are only as reliable as the 
trust that exists between the relying parties and the issuing CAs; and the level of 
assurance achieved by the physical controls, practices and procedures 
implemented by the CAs. 

The purpose of PKI technology is to create and maintain both a secure 
and trusted environment for communicating parties. Such parties rely on the PKI 
to establish the identity of users and to notify them when a user's certificate is no 
longer viable. Certificates are revoked when an individual leaves an 
organization, when a replacement certificate is issued, or when a signing key is 
lost, stolen or compromised. Vendors report certificate status using a wide 
variety of methods. These diverse methods make it more difficult for users to 
obtain certificate status for other users. 

The formation of a trust relationship and interoperability is dictated by PKI 
certificate and security policies and their enforcement. The certificate policy 
determines the level of personal vetting (i.e., the process for validating 



appropriateness of certificate request information and the identity of the intended 
certificate recipient) required (e.g., two forms of picture ID, credit check) to gain 
approval for issuance of a certificate. The security policy dictates the physical, 
procedural and process controls needed to support the application environment. 

There are two prevalent models for creating and organizing CAs. The first 
is a hierarchical CA model that resembles an inverted tree whose top is the root 
CA. The root CA signs its immediate subordinate CAs' certificates. These CAs 
then sign their subordinate CAs 1 certificates* and so on. These relationships 
create certificate chains that form e ach branch branches of the tree. Two CAs 
prove that a trust relationship exists between them by "walking" their respective 
certificate chains until a common node is reached. CAs may be grouped and 
associated with one or more service delivery channels, industry verticals, 
organizations or enterprises. 

In the second model, a CA is created for a single enterprise and provides 
CA services to one or more entities within that enterprise. An enterprise CA does 
not normally have any pre-established trust relationships with any CA of another 
enterprise. Explicit action must be taken to allow interoperability in the form of 
CA cross-certification, whereby two or more CAs that agree to trust one another 
sign each other's certificate and use these cross-certified certificates during 
digital signature verification. Certificates issued by one CA can then be validated 
by the other cross-certified CA and its users. 

CAs revoke certificates when , among other reasons, the information 
contained therein becomes invalid, when the user's private key becomes 
compromised, or when it is necessary to terminate a user's certificate -based 
application privileges. CAs cannot simply delete or retrieve a certificate from its 
owner if it is already in the owner's possession. Instead* the certificate is marked 
as "revoked" in the CA's database and tbgxertificate statusJs published. Users 
of the PKI can then learn of a certificate's validity by requesting certificate status 
from the issuing CA or identified status repository (directory). 

An early method used to report certificate status was by way of publication 
of a list of a CA's revoked certificates, known as a Certificat e Revocation List 



(CRL)Q BL CRLs are downloaded by applications and relying parties to 
determine whether a particular user's certificate has been revoked and by 
extension whether that user's digital signature is still valid or not. With time ± 
CRLs get longer, incurring both communication and data processing overhead. 
An additional shortcoming of this approach is that CRLs are often published at 
infrequent intervals (e.g., once or twice a day). For this reason* CRLs are often 
immediately out-of-date after publication. Revoked certificates are only removed 
from CRLs after certificate expiration. 

A PKI bridge is a method of providing interoperability between CAs by 
coordinating distribution of CRLs. Such a bridge is a central CRL repository that 
in effect joins a set of CAs that agree to accept each other's certificates and 
security policies. All CAs post their CRLs to the bridge. This allows for 
centralized validation of any individuals' or ontitios ' individuars or entity's 
certificate. If the certificate has not been previously revoked, thanlhgQ it is still 
considered valid. The biggest disadvantage to PKI bridges is that they must be 
reachable by any CA or user relying on the bridge for certificate status. The 
bandwidth, computation,, and storage requirements may be costly. 

A more recent method for obtaining certificate status is the I nt e rn e t 
Eng i n ee r i ng Task Forc e ( I ETF) On l in e C e rt i ficate Status Protocol (OCSP). 
QCS PIETF OCSP. which makes a direct database query that can provide real- 
time certificate status. However, some vendors have implemented OCSP 
responders that are based on CRLs. Certificate status reported by this type of 
responder is only as timely as the CRLs on which they are based. Attempts to 
achieve real-time certificate status, such as the IETF Simpl e C e rtificat e 
Va l idation ProtocolS QVE continue to be developed. At the time of this invention, 
mixing and matching of status checking methods has not been practical in an 
open PKI environment. 

Any approach to certificate validation is an all -or -nothing decision for the 
CA that issued the certificates. All users who are issued certificates by one of 
the member CAs are valid/enabled unless their certificate has been suspended T= 
QE revoked or has expired. The common theme for controlling participation is 



whether a certificate gets issued. Issuance is governed by certificate and 
security policies and business rules. 

The trust environment can k eranae from fully open* where anyone able to 
pay the price of admission is issued a certificate, to b e ing closed or bounded* by 
requiring membership in an enterprise or community of interest. In either case, 
CA certificate and/or security policies govern whether interoperability is allowed. 

SUMMARY 

Applicants 1 invention approaches the PKI and CA interoperability problem 
from a totally different point of view than tha tf rom those described i n th e 
background s e ct i on. As i n above. A pplicants' e arli e r inventions, the focus is on 
establishing a trust environment suitable for the creation, execution, 
maintenance, transfer, retrieval* and destruction of electronic original information 
objects that may also be transferable records (ownership may change hands). 
To realize these objectives, the system controlling an electronic original or 
authoritative copy must make it possible to identify the original from any copy 
thereof. As with paper oriainal oriainals. there can only be one original. 
Examples of transferable records are electronic negotiable instruments and 
securities. An electronic original record may be any source record, whether it 
qualifies as a transferable record or not. Transfer of electronic oria i nals oriainal 
records between systems must take place using methods that guarantee that 
only one original exists. 

This invention creates an electronic original record by placing custody of 
that record in the hands of a trusted independent party, functionary or Trust e d 
Custod i a l Uti l ity ( TCU) operated for the benefit of the record's owner. Creating a 
trust environment is a-necessary, but is not sufficient for maintaining electronic 
source records. For the purpos e purooses of this invention, a trust environment is 
created by formation of a community of interest that has a closed or bounded 
membership and where the identity of prospective members, organizations and 
their users 7 is assured by using appropriate vetting procedures that govern the 
granting of admission to the community. Further, an individual's organization, 
participation, role ± and attributes are defined at the time of enrollment with the 



TCU. Individuals must be uniquely identified to the system and in their 
authentication certificate. In addition, it must be possible to remove individuals 
and organizations from the community and to make this action known to other 
members of the community. Traditional approaches to CA interoperability do not 
adequately achieve these objectives. 

Vetting T at a minimum requires that an organization and/or individual be 
sponsored by a known member of the community. In addition, a Dun and 
Bradstreet-PkUke rating for organizations or an Equifax-PfcUke credit check for 
individuals, or an equivalent credit and payment history* may be utilized to 
evaluate acceptability of potential business partners, clients and customers. 
Both the vetting organization and its sponsored users must be deemed 
trustworthy before TCU enrollment is permitted. After an organization agrees to 
the contractual terms defining membership, its sponsored individuals will each be 
given a unique identifier and password that will enable them to access the TCU. 

Once an individual is enrolled with one or more TCUs* they can be named 
as a participant to a transaction by the owner of that transaction and given 
specific access to all or an identified subset of source records based on their 
identity, role* and/or responsibility. To facilitate identification and authentication 
and to enable the transactions to take place in a totally electronic form* a 
selected subset of this identifying information is included in the participant's 
authentication certificate. The authentication certificate binds the user's identity 
with their public-key used to validate digital signatures generated using their 
matching signing private-key. 

A certificate or security policy addresses the proof-of-identity requirements 
(e.g., two forms of picture ID, credit check, personal introduction) needed before 
issuing a certificate. This certificate will be bound to the user's TCU account if 
required for digital signing authority. The linkage shall include a subset of 
certificate data elements that uniquely identify the user (e.g., certificate ID, 
issuing CA name, user common name). Once associated with a user's account, 
the certificate can be used in conjunction with his or its digital signature to afford 
the proof-of-identity needed to enable a predetermined set of authorized actions 



and to verify the user's digital signature on submitted information objects. This is 
especially true when the owner or owner's agent controlling a set of electronic 
recordSr instructs the TCU to transfer ownership (i.e., an internal transaction) 
and/or to transfer custody (i.e., an external transaction) of the electronic records 
to another TCU. 

As described earlier, authentication certificates and public-key 
cryptography are used to support both user authentication and digital signature 
verification. The certificate is digitally signed by the issuing CA, a process by 
which the identity of the recipient is sealed with their public key. The CA asserts, 
in issuing a certificate, that the individual identified in the certificate is the holder 
of the matching private key used to digitally sign information objects or fragments 
thereof. 

This invention differs from other PKI -based e-commerce solutions since 
the PKI is only viewed as enabling and is not the sole basis of the trust 
environment. Sponsorship, contracting for membership, and enrollment are the 
principal factors. Although the certificate and use of public-key cryptography are 
viewed as enabling technology, certificates must uniquely identify and be tied to 
the specific users before they can be bound to that user's TCU account. 

Where certificates are employed, the account may only be activated once 
this binding between certificate and user account is completed. This binding may 
be as simple as adding the Certificate ID and Issuing CA to the user's account 
information or may use other information conveyed by the certificate such as 
components of the user's distinguished name (see ITU X.509 standard). The 
binding information may be conveyed in an enrollment form or extracted directly 
from the certificate as per TCU system security policy. A correspondence check 
may be used to ensure that the user description in the certificate matches that in 
the enrollment data whenever the certificate is used. The user's certificate is 
signed by the issuing CA and its integrity and authenticity are validated using the 
issuing CA's certificate and public key. The collective set of components used for 
identification must be provably unique. Once this TCU account and user 



certificate binding is accomplished, the TCU need only know where to go to 
check certificate status. 

In CA centric environments, a single PKI, cross-certification, or creation of 
PKI bridges (a complex system that performs certificate status checking where 
multiple vendor products are used by numerous CAs) is required for 
interoperability. The common element is that all certificates are of equal value. 
Certificates may convey different trust levels and applications in an open 
environment must have the ability tojnterpret and use these trust levels 
differently. This philosophy can be characterized as "we will build roads that will 
take you anywhere you want to go". Users are vetted upon CA enrollment using 
a variety of criteria (e.g., a credit check, means of payment, cost of the 
certificate). 

A TCU, conversely, is only concerned with a known set of "approved CAs" 
and within that set only those certificates that are associated with its user 
accounts. Any other certificate will be ignored. This philosophy can be 
characterized as "the only roads that will be open to you will be those needed to 
conduct your business". Users are vetted twice, once to satisfy the CA certificate 
policy and a second time to prove that there is a business need for them to be 
enrolled with a TCU. Business rules enforced by the TCU can accommodate 
certificates that are issued at different trust levels. 

SUMMARY 

To date, all certificate status reporting services use a single means of 
reporting certificate status, be it CRLs, OCSP, LDAP, etc. This invention differs 
in that it enables interoperability with any CA or PKI for the purpose of retrieving 
and reporting certificate status. For the most parL it also reduces reliance on 
real-time continuous connectivity between the systems or TCUs and the CA 
certificate status reporting elements, by caching certificate status. 

In one aspect of Applicants' invention, a method of providing a CSS for 
checking validities of authentication certificates issued bv respective CAs 
includes the steps of identifying information needed for retrieving a status of an 
authentication certificate from an issuing CA that issued the authentication 



certificate; configuring a connector based on the identified information for 
communicating with the issuing CA: communicating with the issuing CA 
according to the configured connector: and retrieving the status of the 
authentication certificate. The issuing CA and the connector are designated on a 
list of approved CAs in a configuration store 

A local date and time may be checked for whether they fall within a validity 
period indicated in the authentication certificate validity period. The issuing CA 
ma y be included in the list of approved CAs by vetting and a pprovin g the issuing 
CA according to predetermined business rules, and if the issuing CA is vetted 
and not approved, the issuing CA may be designated on a list of not-approved 
CAs in the configuration store. Vetting and approving the issuing CA may 
include registering a representation of a trusted authentication certificate with the 
CSS and adding at least the representation, status and a time-to-live data 
element to a local cache memory. A connector is then configured for retrieving 
the added status when the status of the trusted authentication certificate is 
gueried. Communicating with issuing CAs mav also be done according to a 
seguence of connectors. 

The method may further include checking a local cache memory for the 
status, and if the status is found in the local cache memory and the local date 
and time are within the validity period, retrieving the status from the local cache 
memory. If the status is not found in the local cache memory or if the local date 
and time are not within the validity period, the CSS establishes a communication 
session with a certificate status reporting component of the issuing CA. 
composes a certificate status reouest according to the configured connector. 
retrieves the status from the certificate status reporting component, closes the 
communication session with certificate status reporting component, and adds at 
least the authentication certificate's identification, status, and time-to-live to the 
local cache memory. 

Certificate status mav he indicated bv a CRL. and according to a 
publication schedule of the issu ing CA. th e CSS retrieves the CRL from a 
certificate status reporting component listed in the configuration store the CSS 



clears a cache memory associated with the issuing CA and the CSS determines 

the status pf the authentication certificate from the CRL and store? the status in 
the cache memory associated with the issuing CA. 

Certificate status mav also be indicated bv a Delta Certificate Revocation 
List ("ACRL"V and upon notification bv the issuing CA that a ACRL is available. 
the CSS retrieves the ACRL from a certificate status reporting component listed 
in the configuration store: if the ACRL is a complete CRL. then the CSS clears a 
cache memory associated with the issu in g CA. determines the status from the 
CRL. and stores the status in the cache memory: and if the ACRL contains only 
changes occurring after publication of a full CRL. the CSS determines the status 
from the ACRL. and stores the status in the cache memory. 

In another aspect of Applicants' invention, a method of retrieving a status 
of an authentication certificate issued bv an issuing CA in response to a ouerv 

from a TCU to a CSS to validate the authentication certificate's status includes 

the steps of locating and reporting the status if the status is present and current 
in a cache memory of the CSS; and otherwise, performing the steps of obtaining 
a status type and retrieval method from a CSS con fi guration store: if the status 
type is CRL and the status is not found in the cache memory, then reporting the 
status as valid: if the status type is not CRL. then composing a certificate status 
reguest according to the status type: establishing a communication session with 
the issuing CA: retrieving the status from a status reporting component of the 
issuing CA using the obtained retrieval method and ending the communication 
session: interpreting the retrieved status: associating, with the interpreted 
retrieved status, a time-to-live value repres enting a period specified bv a CSS 
policy for the status type: adding at least the authentication certificate's 
identification, status, and time-to-live values to the cache memory: and reporting 
the status to the TCU in response to the query. 

In yet another aspect of Applicants ' invention, a CSS for providing 
accurate and timely status indications of authentication certificates issued by 
issuing CA s includes providing a status of an authentication certificate as 
indicated bv a CRL when the certificate's issuing CA uses CRLs for indicating 



status. Otherwise, the status as indicated hy a cache memory when the cache 
memory includes a status and a time-to-live data element is not exceeded is 
provided. If the time-to-live data element is exceeded the status is cleared from 
the cache memory, and the status is requested and retrieved using a real-time 
certificate status reporting protocol when the status is not in the cache memory. 
At least the certificate's identification status, and time-to-live data element are 
added to the cache memory, and the retrieved stat us is provided 

A status use-counter data element may be added to the cache memory 
and incremented or decremented every time the certificate's status is checked. If 
the status use-counter data element nasses a threshold then the status is 
provided and the cache memory is cleared with respect to the status. A status 
last-accessed data element may also be added to the cache memory, and the 
status last-accessed data element in conjunction with the status use-counter data 
element enables determination of an activity level of the certificate's status. 

When a reouest is made to the CSS to retrieve a status of a new 
certificate and the cache memory has reached an allocated buffer size limit, the 
CSS searches the cache memory for a lasted-accessed data element indicating 
an oldest date and clears the respective cache memory entrv: and the CSS then 
retrieves the requested status, places it in the cache memory, and provides the 
requested status. 

In vet another aspect of Applicants' invention, a method of executing a 
transaction between a first party and a second party bv transferring control of an 
authenticated information object having a verifiable evidence trail includes 

retrieving from a trusted repository an authenticated information object that 
includes a first digital signature block having a digital signature of a submitting 
party and a first authentication certificate relating at least an identity and a 
cryptographic kev to the submitting party, executing the retrieved authenticated 
information ohject bv the second party hy including in the retrieved authenticated 
information object the second party's digital signature block and forwarding the 
executed retrieved authenticated information object to a TCU. 



The TCU verifies the digital signatures and validates the authentication 
certificates associated with the digital signatures bv at least retrieving status of 
the authentication certificates from a CSS. The TCU rejects a digital signature 
block if the respective digital signature is not verified or the status of the 
respective authentication certificate is expired or is revoked, and if at least one 
signature block in the information object is not rejected, the TCU appends the 
TCU's digita l signature block and a date and time indicator to the information 
object and takes control of the object on behalf of the first party. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The various features and advantages of Applicants' invention will become 
apparent by reading this description in conjunction with the drawings in which: 

Figure 1 illustrates tbea TCU electronic information object validation 
process that employs the CSS^l 

Figure 2 illustrates tbe-backg round CSS processing whereby CRLs and 
ACRLs ACRLs are added to the certificate status storey 

Figure 3 illustrates separate caching of parsed CRLs, OCSP responses, 
and status derived from other certificate status reporting methods^ 

Figure 4 illustrates an extensible syntax for a signature block containing 
the example data elements where a digital signature is being applied to 
information object fragments and attached data (authenticated attributes)^ 

Figure 5 illustrates TCU interaction with a CSS and CSS retrieval of 
certificate status via the Internet from member and foreign CAs^ 

Figure 6 illustrates thea TCU user enrollment process terminating in a 
certificate status checking step, where digital signature validation demonstrates 
successful enrollment^ 

Figure 7 illustrates thea TCU user enrollment process where a foreign CA 
issued the user certificate, terminating in a certificate status checking step, where 
digital signature validation demonstrates successful enrollmentT^and, 

Figure 8 depicts an automobile-leasino example that shows how a CSS 
can be utilized in electronic commerce. 

DETAILED DESCRIPTION 

The certificate status check is a critical element to a system or TCU 
acceptance of any electronic information object submission. In order for a 
submission to be accepted, the certificate status must be reported as valid. 
Querying for certificate status normally requires that communications take place 
between the TCU and the source of certificate status. The frequency of these 
communications will grow in proportion to the number of TCU submissions. 

Checking of certificate status may be a real-time requirement and status 

queries are performed on every submission. However, status may not be 
updated in real-time as is the case with CRLs. All CRLs are published at 



specified intervals, normally once or twice daily. CRL retrieval and repeated 
parsing can have a negative impact on system performance. This invention 
significantly reduces the direct computational and communication requirements 
by off-loading the bulk of the work to a C e rtificat e Status S e rv i c e ( CSS). A single 
certificate status protocol is implemented between the TCU and the CSS. This 
status protocol may have attributes similar to the IETF Onlin e C e rt i ficat e Status 
Protoco l ( OCSP) that allows thean application to query a CA for the status of a 
single certificate and thus minimize processing overhead. 

The CSS is provided with and maintains sufficient information on the 
location, the means of communication and of processing certificate status for 
every CA that it needs to interoperate with. The CSS therefore makes it possible 
to stabilize and optimize the application design. The CSS advantageously 
parses and caches certificate status to minimize status response time to a TCU 
status query. The CSS therefore eliminates the need for any of the traditional 
forms of PKI interoperability. Potential compromise recovery is greatly enhanced 
since a TCU user account can easily be deactivated or a set of users eliminated 
by removing the CA from the CSS list of approved CAs. 



Us e of auth e nt i cation c e rtificates: 

Use of Authentication Certificates: 

After logging into the TCU a participant may be asked to further 
authenticate themselves though use of public key cryptography and their 
authentication certificate. Such authentication may be associated with secure 
session establishment, requests for TCU services or the digital signing and 
submission of an electronic information object. 

Before anyone can interact with a TCU, four conditions must be met: 1) 
they must first be enrolled as a system user, 2) they must have been issued and 
be in possession of a public-key pair and their matching authentication certificate 
if they are granted more than read-only access, 3) certificates must be issued by 
an approved CA, and 4) the user's certificate must not have expired or be 
reported as inactive or revoked. This last condition normally requires that the 
TCU direct a query to the issuing CA to retrieve certificate status. Because there 
are a wide variety of standards and CA implementations for reporting certificate 
status, this is not an easy or simple task. 



As stated in the background section, normally some form of PKI 
interoperability is required when multiple CAs or PKIs are involved. This 
invention eliminates this need by creating a Certificate Status Service. CA cross- 
certification or bridging is unnecessary as the only knowledge needed by the 
CSS is the list of approved issuing CAs, their IP addresses or the like , and their 
means of reporting certificate status. 

To retrieve certificate status, a connector o r program module is defined for 
each certificate status method. Every authentication certificate contains both 
subject (user) and issuer (CA) fields. The issuer field is used to direct a TCU 
query to the CSS that then checks its cache for the presence of the certificate's 
status. If status is present in the CSS cache* it is returned to the TCU. If status 
is not present* the CSS will invoke the appropriate connector to retrieve the 
certificate's status. Any number of methods will be used for reporting and 
retrieving certificate status^LDAP, OCSP, CRL, etc. 

To perform any TCU action* the user must first log into a TCU. Once 
successful, the user can create or select a transaction if they whor o were granted 
such authority. If they have permission to submit electronic information 
obj e c t objects. they may now do so. Upon receipt of an electronic information 
object^ the TCU performs the necessary digital signature validation steps. A 
certificate status query will be composed and sent to the CSS. If a valid status is 
returned* the TCU will accept and store the submission as the authoritative copy, 
otherwise it will be rejected. 

Digital signatur e proc e ssing and certificate status check i na: Sianature Processing 
and Certificate Status Checking; 

Digital signatures may be applied to one or more fragments or the total 
content of an information object. Digital signatures may belong to the parties to 
the transaction or to agents who enable the transaction to achieve a state or 
status within the context of a business process. Digital signatures may in fact be 
applied to additional information relating to the task being performed. One such 
example might be the county recorder's notation on a property deed. Another 
might be the application of the signature of the party attesting to the authenticity 
of the information objects being submitted to a TCU. In this Jate flatter instance* 
the submitter is said to wrap or seal the information object in that their digital 
signature is applied to the full content preventing any subsequent modification. 



Whenever a digital signature is applied, the signer will be requested to 
affirm their intent to be bound by their digital signature. This commit action, that 
is required by recent legislation, may take the form of readable text in a display 
window or splash screen, and may require invocation of a graphical button and/or 
logon to a cryptographic token that is also a cryptographic key and certificate 
store. The actual demonstration of said willingness to commit is through the use 
of a trusted application that computes the user's digital signature using the 
selected content and combines it with their authentication certificate to the form a 
signature block. The signature block may also contain authenticated and 
unauthenticated data ele m e n t elements . Authenticated data elements are 
included in the digital signature computation (a^local date-time) and may be 
considered protected by the digital signature (integrity). Unauthenticated data 
elements are added after the signature computation and are not protected. 
Figure 4 shows a sample syntax that contains the data elements and layout of a 
signature block. It is not to be interpreted literally as it is only meant to be an 
illustrative example. 

The information object and any signature blocks may be advantageously 
placed in a wrapper (S/MIME) or at tags in an extensible information syntax 
(XML, HTML, XHTML) for handling convenience and to facilitate information 
processing. This data structure is then sent to the TCU for validation. 
Conversely, the signature block(s) may be sent independently to the TCU to be 
affixed to the actual source record which never leaves the TCU. In the 4aterlatter 
case ± each signature block is validated separately. 

The process for digital signature validation differs at the time of 
submission, from that performed thereafter. A four -step validation is performed 
the first time the TCU sees a digital signature: 1) verify the digital signature, a 
process that proves that the content protected by the digital signature has not 
been altered during transmission; 2) check that the current TCU time falls with 
the allowable validity period of the individual's authentication certificate ("not 
before", "not after"); 3) request and retrieve certificate status from the issuing CA, 
CRL distribution point* or another approved source of certificate status using the 



locally assigned CSS; 4) validate that the TCU user account information agrees 
with that conveyed in the certificate and that the requested action is authorized in 
the TCU rules database. For a submitter of the information object, the process 
adds one add i tion additional step. This fifth step checks that the submitters 
identity matches that of the party who established the current session with the 
TCU. If all tests succeed* the action is allowed and/or the information object is 
accepted and held by the TCU on the behalf of its owner. If any step fails* 
remedy is initiated. 

After this initial certificate status check, the trust environment of the TCU 
maintains the authenticity and integrity of all held information objects. It is not 
anticipated that any additional certificate status check will be needed unless a 
new version of the document is submitted. 

Two aspects of this invention differ from the normal course of PKI 
implementation. The first is that this invention is based on the existence of an 
application, namely the TCU (or any application/system requiring certificate 
status validation) and its ability to create and maintain electronic original source 
records. The second is that "issuing CA" need only be identified as complying 
with the policies governing the trust environment and that neither CA cross- 
certification nor PKI bridging is required. The necessary justification for "issuing 
CA" inclusion is a documented business relationship. During the TCU enrollment 
process, a user account is created that references user specific certificate 
information that in effect binds the user account with the user's authentication 
certificate. 

TCU usejJsfi: 

Typically once an organization agrees to utilize the services of a TCU, 
control over access to that organization's transactions is granted to agents of that 
organization. The organization's agents then identify a set of individuals whom 
they will empower to perform selected actions with regard to the organization's 
transactions. All actions require that the user have an account with the TCU, that 
the account be activated, and that the user have a logon identity and be able to 



provide an appropriate password or response to a challenge phrase. In addition, 
each transaction, which is composed of a set of versioned electronic original 
source records, has a set of permissions that govern user access at different 
steps in the business process. This is exemplified by the granting and removal of 
rights to transaction records as the transaction proceeds though the normal 
course of business, i.e., inception through permanent retention or destruction. If 
permitted, only logon to the TCU is required to view an electronic source record. 
However, any systems level action or the introduction or changing of an 
electronic source r e cordsi gcoEd requires the individual to either further 
authenticate themselves by using public key cryptography or by applying their 
digital signature and authentication certificate. In all instances* the identity of the 
individual must be validated. Where digital signatures are employed* this 
entails^; 1) that the user has appropriate access permissions, 2) decrypting the 
digital signature and verifying the contents over which the underlying hash or 
message digest has been applied have not been altered, 3) checking that the 
time of submission falls within the certificate validity period, and 4) checking that 
the user certificate is still valid. 

Certificate status checking requires that the issuing CA or a certificate 
status responder be queried. Since this step must be taken with every 
authenticated action or electronic source record submission, communication 
bandwidth may become excessive and potential exists for delays, backlogs* and 
rejections due to unanswered or slow status responses. This invention 
addresses these and other high assurance aspects of operating a TCU and 
ensuring the validity of all parties interacting with the TCU. 

In the highly assured environment in which the TCU is operated, certificate 
status checking is only needed when a service is requested by a qualified user. 
For information objects, certificate status need only be checked at the time of 
submission. If all digital signatures are determined to be valid, the information 
object is deemed authentic thereafter. Security and procedural practices and 
methods are in place at the TCU to prevent malicious actions and hardware 
failures that result unauthorized document alteration or loss. Every submission 



results in creation of a new version of an electronic source record. The TCU is 
charged with maintaining knowledge as to which is the latest version of the 
source record. This version may be identified as the electronic original and as a 
transferable record. The TCU demonstrates its assumption of control of an 
original source record by adding a reliable date-time stamp to the source record T 
and then by applying its dig i ta l ly s i an i na diaital signature and appending its 
certificate. A wrapper may be applied to the source record for security and 
processing expediency. Although this versioning process creates a standalone 
authenticated trail-of-evidence and custody, separate redundant audit records 
are maintained for corroboration. 

A Certificat e Status S e rv i c e is pr e s e nt e d tha tA DDlicants , CSS overcomes 
the described limitations that persist today with PKI and e-commerce. Source 
information required to obtain certificate status from member CAs is registered 
withjhs CSS when they are created. Source information for foreign approved 
CAs may be entered during the user enrollment process. CSS retrieval 
information is required for every certificate status source. There are several 
types of certificate status sources and the CSS is required to have a connector or 
method for each type r registered. 

One method used by some CAs to convey certificate status is ca l l e d a 
C e rt i ficat e R e vocat i on List. At he CR L. which includes a list of revoked 
certificates and the reason for their revocation, the issuer of the CRL, when the 
CRL was issued, and when the next version of the CRL will be published. Every 
CRL is signed by the issuing CA or a designated signer to assure its integrity and 
authenticity. Certificates are removed from the CRL once their validity period is 
exceeded. 

Where CRLs are used, the CSS retrieves the latest rendition of the CRL 
from the CA distribution point, e.g., an X.509 v2 CRL profile (IETF RFC2459, Jan 
99), validates its signature, parses it, and creates a cache to store the results. 
The CSS uses a CA's CRL publication interval to govern when it performs the 
next CRL download. Every CRL contains a validity field that is normally set to 
allow some leeway in performing downloads. This allows for communications 



congestion and CA downtime and will force the CSS to require remedial action if 
this interval is exceeded. Such remedy may include revalidating any 
submissions that are associated with a newly added revoked certificate. Each 
new CRL supersedes the previously loaded CRL. The exception to this rule is for 
delta CRLs procession. The contents of a delta CRL are appended to the current 
cache contents. The delta CRL BaseCRLNumber refers to the most recent full 
CRL issued. Delta CRLs are published at shorter intervals (minute, hour) and 
only when a certificate revocation has occurred since the last full CRL. The CSS 
is responsible for retrieving CRLs and delta CRL based on publication interval or 
notification and not to exceed the interval established in the TCU security policy. 

A second method used by CAs to distribute certificate status is the On l in e 
Cortificato Status Protoco l ( OCSP). Where OCSP is used the CSS queries the 
OCSP responder when asked for certificate status. OCSP responses are signed 
to guarantee their integrity and authenticity. The CSS parses the OCSP 
response and adds certificate details and status to another cache. A time-to-live 
flag, determined by local TCU security policy, is included with and determines 
when the entry will be removed from the cache. This feature is aimed at 
minimizing communications overhead when several information objects are be 
uploaded by the same party/entity to the TCU in a short interval. The time-to-live 
flag will usually be significantly shorter (e.g.. 5 minutes) than the normal CRL 
publishing interval (twice daily, daily). The CSS may check certificate status 
again, if more than one information object was processed, prior to purging 
certificate status from the cache to ensure that certificate revocation has not 
occurred. If certificate revocation has occurred during the time-to-live interval, 
then the owner organization point of contact must be notified. Several other 
query methods exist, but will not be described for brevity. Be it understood that 
they will each require a connector and potentially a separate cache when they 
are utilized. 

Figure 1 shows the process flow n e cessary to cr e at efor creating an 
electronic original. For the purpos e purposes of-#*e description, the information 
object is assumed to be a sales contract. An e Stored^ copy (unexecuted) of the 



electronic information object is retrieved fefmfmm the TCU or from a document 
preparation system . An app l ication fo ll owing th e proc e ss st e ps out l in e d in th e 
claims is used in executing th e contract 1a aQdJa digitally or holographically 
(handwritten) signed by appropriate parties. Having overseen the execution 
process* the owner's agent uses a trusted application to digitally sign and wrap 
the information object T and send it to a TCU. 

Having previously created, executed or retrieved the electronic document, 
thea submitter digitally signs and submits it to the Trust e d Custod i al Ut i lity ( TCU) 
as in step 101 . In th ethis eSeal process th e syst e m appl ie s* a wrapper that 
contains the signed content and digital signature block(s) that further contain the 
digital signature(s) and certificates(s) of the submitter and any other signatory_is_ 
formed . There are five processes represented in the figur e : Figure 1: (1) action 
when an invalid digital signature(s) and/or revoked certificate(s) is found, (2) 
certificate status checking where status is locally cached, (3) certificate status 
checking where certificate status has to be retrieved, (4) CRL retrieval and 
processing, and (5) conc l ud i ng w i th creation o fc reatina an eOriginal when the 
eSeal document is determined to be authentic. In step 103 the TCU receives the 
eSealed electronic document. In step 105 the TCU validates that the submitter 
has authority to add the electronic document to thea selected account and/or 
transaction. In step 40 7107. the TCU cryptographically verifies any digital 
signatures included in the electronic wrapped digital electronic document. The 
public key, found in the signer's X.509 authentication certificate, is used during 
the verification process. In step 4Q Q109. the certificate validity period is extracted 
from the signer's authentication certificate* and in step 444-441 1 1 . the validity 
period is checked against the current date and time. If any of the before 
m e ntions mentioned tests fail* the submission is rejected in step 113 and a 
negative acknowledgment may be sent in step 114. The action is logged in step 
117. 

If all tests succeed, toaftjtian certificate status for each certificate 
contained within the wrapper is requested from th e C e rt i ficat e Status S e rvic e 
(GSS>a=QSS in step 119. In stepsteBS 121 and 42 3123. certificate status is 



checked to see if it is present in then certificate status store. In step 425:L2fL 
certificate status is retrieved* and certificate validity ^checked in step 127. If any 
certificate is found invalid for any reason, the submission is rejected in step 113, 
a negative acknowledgment may be sent in step 115, and the aetion saction is 
logged in step 117. The submitter is expected to seek remedy. 

If in step 127 all digital signatures and certificates are determined to be 
valid for the submission, then in step 129 the TCU w ill app l y applies another 
wrapper that includes a date-time stamp T== and TCU digital signature block. The 
TCU then assumes control of the submission as an electronic original record on 
behalf of the owner of record. In step 43 4131. the TCU places the electronic 
original in protected persistent storage, in step 433133. the TCU sends a positive 
acknowledgment, and in step 44 7117. the TCU logs the actions just completed. 

If in step 123 it is determined in-that the certificate status is not present in 
the certificate status store, tha ftthen the CSS in step 135 retrieves the issuing CA 
field from the certificate under test. In step 43 7137. the CSS checks to see that 
the issuing CA is on the approved CA lisl, which may be maintained and 
accessed bv a CA Connector Store in step 139. If the CA is not listed4haB a JhfiQ 
an invalid status is returned and the process resumes at step 125. Th e 
proc e ss 125 and proceeds through stepstses 1 27, 113, 115, and 44^ 7117. 
resulting in rejection of the submission and transmission of a negative 
acknowledgment and log entry. If the issuing CA is found on the approved CA 
list in step 1 37 and in step 141 it is determined that the certificate status reporting 
m e ans is a C e rtificat e R e vocation List (CRU than mechanism is a CRL. then a 
valid status indication is returned to step 125. If the CA is known and status is 
not present for the subject certificate, but the status m e ans i s by C e rtificat e 
R e vocat i on L i st (CRLl than mechanism is a CRL. then it may be assumed that 
the certificate status is valid* providing a CRL exists and is current for the CA. 
The process tbartthen proceeds through steps 127, 129, 131, 133. and 433117. 
resulting in the creation of an electronic original, the transmission of a positive 
acknowledgment* and a log entry for the actions just completed. 



If in step 141 the certificate status reporting mean smechanism is 
determined not to be a CRL-tbaft^Jhen the connector information obtained in step 
137 is used to query the certificate status reporting meaft smechanism . 
Contained in the connector description is all configuration information needed to 
query the appropriate certificate status repository, be it a_CA J= a directory, or any 
other type of certificate status repository. The status stores associated with 
steps 145, 147, 149, and 151 (i.e.. respectively, an LDAP directory, an OCSP 
responder. a database, and a server) are examples of such repositories. In 
response to th e qu e ry, on e th e four st e ps M45. 147. 1 4 9. or 151) r e soond a auerv 
in step 143. one of these responds with certificate status information, and the 
status is added to the certificate status store in step 153. 

Upon addition in step 153. t he certificate status in-store process resumes 
at step 121 and continues through stepsteBS 123, 125, and 127 to a=conclusion 
where the submission is either accepted (steps 129, 131 , 4^ 3133. 117 ) or 
rejected (steps 113, 115, 117). 

CRLs are published in step 155 at predetermined intervals and in step 157 
as needed when a suspected compromise is reported and policy requires an 
immediate response. This process is further described in fiew eFiaure 2. 

If the CA is kno wknown and status is not present, and the status 
m e ans mechanism is other than 3=0 RL, the Certificate Status Service selects a 
connector and queries the certificate status mean smechanism (step 44 2143 ). 
The connector contains the necessary information that makes status retrieval 
and interpretation possible. Any of the possib le sources of real-time certificate 
status depicted in steps 444 — 150, but not l im i t e d on l y to th e s e m e thods, 145^ 
151 will respond to a certificate status query with current status , but this process 
is not limited only to those sources . Status is received in st e p 152 and added to 
the Certificate Status Store in step 44S r153. When status is added, a response 
is generated and action returned to step 118 wh o roin 123. with the processing of 
status r e sum e s resuming in step 426J2S and comp le t e s completina as 
d e scrib e s described previously. 



Referring now to Figure 2, the Cert i ficat e Status S e rvic e ( CSS) performs 
CRL retrieval as a background process. A CRL contains a list of all revoked or 
suspended certificates until the current date and time is beyond the validity 
period contained in the certificate. Suspended certificates are treated as if they 
have been revoked, butthe^Lmay be reinstated which results in their removal 
from the CRL. Revoked certificates cannot be recovered. 

In step 45 5155. a CA Administrator configures the CA to publish CRLs at 
predetermined intervals. In step 45 7157. the CA Administrator may also- 
manually publish a Delta CRL as dictated by the local certificate or security 
policy. The CA Administrator or CA will push notice on publication of a Delta 
CRL. A d e lta CRLs Delta CRL may be generated whenever a certificate is 
revoked or suspended during the interval between publications of the full CRLs. 
Delta CRLs may contain a complete list of revoked CRLs. In step 2O4201. CRLs 
and Delta CRLs are published to a CRL repository or directory. 

In step 203202* the CSS retrieves the CRL publication sch e du le s schedule 
or Delta CRL notice . St e p , and step 205 represents a timer used for scheduled 
retrieval. The timer also allows retrieval based on the "next update" field 
contained in all CRLs. In step 20 7207. the CRL or Delta CRL afeis retrieved 
from the CRL repository. In step 2O Q209. the CRL or Delta CRL is parsed prior 
to being added in step 153 to an appropriate cache or list in the Certificate Status 
Store in step 121 or directory based on the established schedule or upon 
notification. Parsing the CRLs allows for easier management and reduced 
overhead in CRL entry lookup. Steps 119. 123. 125. 135. 137. and 141 of the 
CSS are illustrated in Figure 2 for completeness, and are implemented as 
described in connection with Figure 1. 

Referring now to Figure 3, the Certificate Status Store contains a number 
of caches that hold certificate status from different reporting meafi smechanisms . 
The caches (five of which are depic ted in Figure 3) may map to individual CAs ef- 
a coll e ction(caches 301. 303) or collections of CAs (caches 307. 309V For real- 
time reported status, the status wil l r e ma i n remains in the cache until space is 
needed (e.g.. least frequently used) or based on a policy requirement (iLa^hold 



for only a specified time interval). Status is normally purged once the 
Gritefi acriterion is exceeded. 

The purpose of the caches is to hold certificate status for a policy dictated 
period, thereby provid i ng a moans to roduc e reducino communications overhead 
required during certificate status and CRL retrieval. The CSS therefore prov i des 
a m e ans to can bridge communications outages. 

CRLs may be parsed and the individual revoked certificate statuses 
placed in a cache to reduce computational overhead resulting when the CRL has 
to be checked repeatedly. This is depicted by the caches 305. 307. The 
contents of the cache are replaced whenever a new full CRL is retrieved. 

Referring now to Figure 4, an example syntax is shown representing some 
of the more important data elements that need to be included in a digital 
signature block. Figure 4 is a free form example of data elements that make up a 
digital signature where the signature is applied to multiple message fragments 
and a date/time stamp. This example is meant to be illustrative of the syntax that 
may be used for a digital signature block. It may be noted that the 
<CumulativeHashValue> data element is applied to HashValues of one or more 
fragments or the total content and any Authenticated Data. 

Figure 5 depicts a secure communications architecture showing the 
building blocks that support the Certificate Status Service. The CSS isfiflura, 
shows the interaction among three CAs. the CSS, and the TCU. The CSS is 
preferably placed local to the TCU to guarantee high availability. Its primary 
purpose is to provide the TCU with a common interface- and to assur e ensure 
secure and timely provision of certificate statu s information , ttlts secondary 
purpose is to msufegnsuEg a guaranteed level or quality of service by managing 
communication and computational overhead required in maintaining certificate 
statusr information. 

As seen in Figure 5. the CSS server and the TCU. with a suitable 
communications router and hub, are advantageously disposed behind a 
communications firewall. The router and hub direct information to the CSS and 
TCU as appropriate. Some of this information comprises eSeal submissions that 



are directed to the TCU as described above through a network such as the 
Internet from a User Client Application. Also depicted are CSS and TCU 
communications via OCSP. 

Figure 5 also depicts three CAs in different exemplary environments 
behind respective communication firewalls. An En ter prise CA might comprise a 
server that interfaces with a Lease Industry CA enclosed by the dashed lines. A 
Foreign PKI or Responder might comprise a server that interfaces with entities 
such as a PKI. CA. and certificate status responder. A Hierarchical Member PKI 
might include a server that interfaces to entities such as a V3 LPAP for CRLs 
and certificate status, a Root CA t and CAs for the mortgage and lease industries, 
lenders, closing agents, and title insurers. 

Figures 6 and 7 depict the use of the Certificate Status Service during the 
user (subscriber and entity) enrollment process for both member CAs and foreign 
CAs . respectively . A member CA is one that is trusted to issue user certificates. 
Foreign CAs are those operated by outside entities and need to be approved 
prior to their certificates being used in conjunction with TCU activities. User 
identity authorization needs to be rigorously enforced by all C ACAs or delegated 
to organization agents. Th e on e A n additional requirement is that a user's 
c e rtificat e s certificate needs to be directly associated or authorized for use with 
one or more subscribing organizations' accounts before the TCU can grant 
access to that user. Once this is accomplished,, the TCU will accept the user's 
digital signature and rely on the en-CSS for certificate status validation. 

In Figure 6, the TCU enrollment process starts at step 601 with receipt by 
an organization administrators/ag e nts r e c e ip t 's administrator/agent of user 
enrollment information from a sponsor . In step this administrator/ agent 

is charged with validating the sponsor's authority to make the request. Sponsors 
are normally only given control over their accounts. In step 60 5605. the 
administrator/ agent enrolls the user with thejTCU ± setting up a user account. In 
step 607607. the administratorZagfiOl may then assign the us e r t ransaction 
privileges . Th e abi l it y to the user. Transaction privileges may include abilities to 
submit, version, transfer, etc. electronic originals and other source records. 



In step 6©9£Q£L a cryptographic token (digital signature 
m e ans mechanism ^ is initialized, and in step 644 61 1. a public-key pairja^ 
generated on the t oken s. In step a certificate request is created, and 

in step 64 5615. the request is sent to the organization's CA. In step 64 7617. the 
certificate is retrieved and pJaceglacgd on the token. In step 649fHiL the 
certificate is bound or associated with the user's TCU account. 

In step 62462 1 T the use r i s r e quested to app e a r 's identity is validated, for 
example by appearing in person so thatt o the organization 's administrator/ aaent 
who can personally validate the user's identity. Normally, at least two forms of 4©- 
ar eidentification would be required. Since user participation is sponsored ± this 
should be sufficient except for high valued transactions where someone known to 
the administrato r/aaent may be asked to vouch for the user's identity. In step 
623622L the user is asked to sign a contract agreement whereby the user agrees 
that the i r use of thei rthe user's digital signature is binding. In step 62 6625. the 
user is given an application user manual and whatever instruction is deemed 
necessary. In ste psteps 627 and 629. t he user is provided with a-logon tOJDs, 
temporary password passwords . and tbeifihs cryptographic token. 

In step 634031^ the user is ask e d to logj og^ onto the system^ and in step 
633S33* submits a test document to the TCU. In step 636225. the TCU validates 
the user's digital signature and certificate. In step 63 7637. the TCU queries the 
CSS for certificate status information . In step 638S3SL the TCU receives status 
and proc ee d proceeds accordingly. If the received certificate status is valid.,, 
enrollment completes at step 64 4641. and the user is able to access and use the 
TCU. If the certificate status is invalid^ enrollment terminates^Th e in step 643. 
and the administrato r must d e t e rmin e / agent determines the cause of the error 
and institut e institutes remedy4kat fc= whi£h may reqyifeinvQlva repeating some or 
all of the outlined enrollment process steps. The reliable process outlined 
mswe sin Figure 6 ensures that the enrollee is fully enabled at completion. 

In Figure 7, the user is allowed to use a cryptographic token previously 
issued by a foreign CA if policy dictated conditions are met. As 
proviousl v described above , enrollment steps 601 through 607 are followed. User 



identity verification and contract steps 621 through 627 are also followedTjis. 
described above. 

Since the user already has a token ± the process deviates from that 
described in fiow eFigure 6. In step 7Q 4701. the user i s ask e d to plac e 
thei fplaces the token in a compatible reader and te glogs on. In step 70 5703. an 
Administrato r administrator application retrieves the user's certificate from the 
token. In step 70 5705. the certificate information is displayed and the Issuing CA 
identification information is obtained. The CA information is used in step 707 to 
verify that the CA is on thean approved list. If the CA is not on the approved list, 
the CA information is provided to the TCU administrator in step 709, and the 
administrator checks with ihean Application Policy Authority in step 711 for 
permission to continue enrollment. Only the Application Policy Authority can 
authorize adding a foreign CA to the approved list. 

If permission is denied in step 713. enrollment terminates^-Th e in step 
649. giving the user-has three options. One is to ask for and use a token issued 
by a member CA. Tw eAnother option is to request a review of the CA rejection 
decision. Thre eThe third option is to ask for the names of previously approved 
foreign CAs. 

If the Issuing CA is approved 7 but not on the Vis U in step 713. in step 715 
the Administrator will b e dir e ct e d to add th e C A administrator adds the CA and 
connector information to the approved lis t. Th e Admin i strator w i ll a l so n ee d to 
configure , configuring the CSS to retrieve certificate status from the CA. 

In step 64 0619. the user's certificate is bound or associated with the newly 
created user account. As in figur e 6. Figure 6 and proc e ss steps 631 through 
639, the user is asked to make a trial submission to the TCU to validate that the 
account has b ebeen set-up correctly and that the user can access the TCU. If 
the CSS returns valid status information, then enrollment completes at step 641 . 
If the CSS returns invalid status ± then the administrator must- 
d e t e rmin e determines the cause of the error and institut einstitutes remedy . This fa 
which may r e qu i r e involve repeating some or all of the out li n e d enrollment 
process steps described above . The mustmnst likely cause of failure may relate 



to the CSSIs being able to reach and correctly retrieve certificate status from the 
foreign CA. 

The CSS plays a vital role in validating that the user certificate and issuing 
CA are both authorized in accessing a TCtJ or other system . If an issuing CA is 
removed from the approved list and its connector configuration data deleted, all 
associated users will be are denied further access to the TCU. It should be 
understood that the CSS can work with other applications and systems that 
require certificate status, including applications and systems t hat require inter- 
working with multiple PKIs and CAs. 

For example, another use of the CSS is to p rovide status for trusted 
authentication certificates, including self-sianed ce rtificates where an agreement 
exists between the client seeking services and the application operator A 
representation of a trusted certificate (e.g.. PEM. certificate ID. applied digital 
signatured is cached by the CSS, and status is Queried using a trusted-certificate 
connector This allows the application to have a single certificate status means 
regardless of whether the certificate was self-signed or issued bv a CA. This 
trusted-certificate method mav be used where a small number of controlled 
certificates are used bv a community rather than Querying the community's CA or 
CAs. Thus, it will be appreciated that the terms "CA" and "issuing CA" as used in 
this application encompass such an accepted issuer of self-sianed certificates as 

well as conventional CAs, 

Furthermore, the CSS mav use a combination of connectors to retrieve 
certificate status. At least one connector mav be "virtual", such as that iust 
described for use with trusted certificates. The CSS invokes connectors in a 
predetermined, e.g.. ordered, sequence until certificate status is acquired. This 
method enables creation of a hierarchy of status sources (e.g.. most-trusted to 
least-trusted V 

Figure 8 depicts an automobile-leasing example that shows how the CSS 
is utilized in e-commerce. The automobile dealer or the dealer's representative. 
hereafter called the dealer for simplicity, was issued a respective authentication 
certificate bv an Automotive CA. which is depicted as a computer. The car's 



lessee, who mav be present at the car dealership, was issued a respective 
authentication certificate bv a Bank CA A remote lessor was issued a respective 
authentication certificate bv a Financial CA. Alternatively, either lessee or lessor 
mav have created a self-sianed certificate, which the dealer registered with the 
leasing application and the CSS, for example because the lessee is a regular 
customer of the dealer. 

As explained in this application the CSS retrieves and reports status for 
these and other certificates using any certificate status reporting means that uses 
an approved status reporting protocol. In Figure 8. it is assumed that Automotive 
CA and Financial CA use OCSP. that the Bank CA uses a CRL. and that the 
dealer and lessees have some forms of token (e.g.. PKCS#11. PKCS#12. 
browser kev store etc /> that contain their certificates and cryptographic signing 

means, it will be appreciated that Figure 8 is just an exemplar of execution of a 
transaction; more or fewer CAs may be connected as necessary with 

communications as necessary for the particular transaction. 

In step 801 the dealer either originates the lease contract or retrieves it 
from a leasing application, such as a computer program running locally at the 
dealership or remotely at a remote site e g on an Application Server In step 
803. the dealer orchestrates the execution of the lease bv the lessee and lessor 
The lease may be d isplayed to both the local lessee and the remote lessor at this 
time, and the dealer may be called on to answer any questions and make 
corrections if needed. The dealer mav arrange for displaying the lease to the 
lessor bv providing a URL (uniform resource locatoh to the lessor that enables 
the lessor to review and execute the lease, with the executed version returned to 
the dealer. After local signing bv the lessee and the dealer, for example with a 
tablet pc that captures the lessee's digital signature on the lease, and remote 
signing by the lessor, the lease is transmitted (step 805) to an Electronic Vault, 
which is shown in communication with the Application Server. The digital signing 
bv the lessee and dealer is advantageously dynamic, with the Application Server 
updating the displays bv applying a "digitally signed bv" indicator to the displayed 
imaoersV The actual digital signatures are preferably not displayed 



It will be recognized that the Application Server and associated Electronic 
Vault mav be used bv the dealer to stane the contract for remote signing bv the 
lessor. In steps 807 through 81 1 the lessor retrieves the lease from the vault, 
agrees to the terms of the lease bv digitally signing it. and returns its digitally 
signed version to the vault. Steps 807 through 81 1 illustrate both multi-site 
collaboration and asynchronous transaction processing. 

In steps 813 through 817. the received electronic documents (the lease) 
are checked for digital signatures, and if any are found, the digital signatures are 
verified and the respective authentication certificates are validated. In step 817 
the local time is checked to ensure that it falls within the validity periods of the 
certificated V and in step 819. the CSS is gueried for the status of the 
certificate(s). In response in step 821. the CSS first checks its local cache 
memory or data store for certificate status, and if a certificate's status is present 
and current, the CSS returns the certificate's status as "active" in step 827. In 
step 823. if certificate status is not present or not current, the CSS gueries the 
issuing CA using the connector type created for this purpose. In step 825, the 
issuing CA, e.g.. the BanK CA. or its status reporting means (e.g.. directory) 

returns status to the CSS, preferably using the same connector, and in step 827. 
the CSS reports the gueried certificate's status back to the Application Server- 
Assuming all digital signatures and certificates are verified and validated. 
proving the electronic document authentic the Application Server assumes 
control of the electronic document and saves it in the Electronic Vault as a new 
version in step 829. Thus, it will be seen that, with the proper characteristics, the 
Application Server and Electronic Vault cooperate as a TCU. | n step 831 . the 

new version is designated as an authoritative copy an Flectronic Original that 
mav also be a transferable record, bv appending a date-time stamp and applying 
the TCU's digital signature to the document. As long as at least one digital 
signature on a docu ment is valid, this step takes place 

In step 833 if anv digital signature or certificate fails to pass all tests the 
dealer is alerted to seek remedy, which typically invol ves repeating steps 801 
through 829 until valid replacement digital signatures are applied. The remedy 



process cannot be completed if the status of a signer's certificate is revoked or 
expired until a new certificate and cryptographic material are issued. 

It will be understood that an information object, such as a lease for an 
automobile, mav be presented in an electronic form, e.g.. XML. PDF. PKCS#7. 
S/MIME. etc.. that enables placement and detection of digital signatures and 
prevents unauthorized modification. Many of these forms therefore can be 
considered as providing security wrappers or envelopes for the included 
information. 

It will also be understood that the CSS can be used to check status of 
certificate s regardles s of kev usage. Such certificates include, but are not limited 
to those for which the primary use is not identity and authentication e g kev 
agreement/exchange, certificate signing. CRL signing, kev encryption, data 
encryption, encrypt only, decrypt only, and secure sockets laver fSSLl 
Accordingly, it will be understood that as used in this application the term 
"authentication certificate" generally encompasses such certificates that are not 
used for identification. 

In addition, a CSS connector can advantageously embed more than one 
certificate status che ck in a single communication. Among other things, this 
capability mav he us ed in validating some or all of a chain of user/entitv 
certificates and CA certificates, e.g.. a hierarchy of CAs from a Root CA down to 
an issuing CA. This provides additional assurance that all CAs in the certificate 
path are still valid. 

This application has described a method for c onfiguring a Certificate 
Status Service (CSS) that includes the steps of determining setup information 
needed to retrieve certificate status for a reouisite issuing CA. identifying a 
connector compatible with a certificate status lookup technique used to retrieve 
certificate status from the issuing CA. configuring the connector with setup and 

communications parameters specific to the selected connector and the issuing 
CA. and setting up a CSS mapping between the issuing CA and the connector. 
The CA designation and connector is added to a list of approved CAs in a 
configuration store. 



A method for executing a transaction bv transferring authenticated 

information objects having respective verifiable evidence trails includes the step 

of retrieving bv a first party from a trusted repository an authenticated 
information object. The authenticated information object includes a first digital 
signature of the submitting party, a first certificate relating at least an identity and 
a cryptographic kev to the submitting party, a reliable date and time a digital 
signature of the trusted repository, a certificate relating at least the identity and 
cryptogr aphic key to the trusted repository: the digital signature and certificate of 
the submitting party having been validated bv the trus ted repository at 
submission attesting to the information object's authenticity: and the 
authenticated information object having been placed in storage as an electronic 
original information object placed under the control of the trusted repository. 

The transaction execution method further includes the steps of requiring 
anv signing entity to commit to use of and to be bound bv their digital signature 

prior to the act of signing, executing said information object by any party, consists 

of inclusion of at least the digital signature and authentication certificate of the 
signing p arty, creating a signature block that contains at least the digital 
signature and authentication certificate of the signing party, associating the 
signature block with the information object repeating the previous execution 
steps where multiple entities digitally sign the information object and/or wrapper, 
and forwarding the digitally signed and/or wrapped information object to a TCU 
The TCU verifies every digital signature and validates each associated 
authentication certificate and retrieves status from a CSS. The signature blocks 

are rejected if the signer's digital signature does not verify or a signer's 

authentication certificate has expired or is reported to be revoked. Rejection of 
anv signature block results in a reouest for a replacement signature block or 
initiation of remedy. If at least one signature block is determined to be valid, the 
TCU appends its own signature block, also containing reliable date and time to 
the subject information object, creating an electronic original which it holds and 
controls on behalf of the owner. 



Creating a digital signature block mav include the steps of computing one 
or more content hashes for the one or more information object fragments or for 
the whole information object, computing a hash over the one or more content 
hashes and anv appended data, such as the local date and time, signing 
rationale or an instruction encrypting the computed hash using the signing 
party's private kev. thereby forming the signer's digital signature, and placing the 
signer's digital signature in the signature block along with the signer's 
authentication certificate. If the appended data includes a local date and time- 
creating a digital signature block may further include the steps of either 
displaying the local date and time, reouirino a signer to affirm that the date and 
time are correct, and correcting the local date and time if either is incorrect, or 
relying on a system date and time if these are set bv a trusted time service and 
local date and time is protected from tampering. The local date and time can be 
checked to ensure that it is accurate and that it falls within the user's 
authentication certificate validity period and that the local data and time is not 
before and not after the dates and times specified bv the validity period. 

Remedy of a digital signature that fails to verify reouires the digital 
signature to be recomputed and the signature block to be retransmitted. 
Remedying a violation of authentication certificate validity period includes 
notifying the user that the user's certificate has expired and must be renewed and 
notifying the transaction owner that the transaction is incomplete. 

Placement of one or more signature blocks and the information contained 

therein is specified by at least one signature tag, One or more handwritten 
signatures and dates are digitized and used for information object execution, and 
placement of the signatures and dates is specified by at least one signature tag- 
One or more signature blocks can be sent to the TCU separately along with the 
designation of the corresponding signature tags and the TCU can validate every 
signature b lock sent independently or as a grou p. If either the digital signature 
verification or authentication certificate validation step fails, the TCU rejects the 
signature block and may reguest remed y, and if the signature block validation 
step succeeds, the T CU places the signa ture block at the indicated tag. To 



signature blocks sent separately, the TCU mav add a reliable date and time to 
each signature block. According to business rules, the TCU appends its own 
signature block that contains a reliable date and time in a wrapper that 
encompasses the subject information object and inserted signature block fields. 
thereby creating an electronic original information object. Multiple user 
signatures blocks mav be added within a wrapper, and wrappers can be 
recursively applied to implement other business and security processes. 

The TCU may validate the digital signatured and authentication 
certificated present in a signature blockd that is/are to be contained within or 
is/are to be added to content of an electronic original information object bv 
checking in the business rules database that the signing entity identified bv the 

authentication certificate has authority to perform the requested action, verifying 
the signing entity's digital signature, checking that certificate validity period. 

overlaps current reliable date and time, checking that the conveyed local date 
and time falls within allowable deviation with the TCU date and time, and 
checking certificate status using a CSS. If anv of these steps results in an invalid 
or false output, the digital signature is deemed invalid, the reguested action is 
disallowed and remedy sought: otherwise, the digital signatu re is deemed valid 
and the requested action is allowed. 

Registration of an issuing CA with a CSS may include the steps of vetting 
and approving the issuing CA for inclusion in a CSS knowledge base as 
"authorized" based on industry or organization business rules and system policy. 
If the vetting step fails, the issuing CA is added to the CSS configuration store as 
"not authorized" and/or CA registration terminates: otherwise, the issuing CA is 
added as "authorized", and the communication parameters (IP address, SSL key 
and certificate) and the method used for reporting certificate status (OCSP, CRL, 
LDAP1 are added to the CSS configuration store, and the connector to interpret 
certificate status is added if not already implemented In this wav the CSS 
enables interoperability between a system or TCU and a diverse set of certificate 
status responders. 



Certificate status checking advantageously employs a CSS for 
establishing communications, retrieving and caching certificate status from 
approved certificate issuing CAs. When CSS receives a certificate status query 
from a system or TCU. the CSS first checks its local cache to see if the certificate 
status is present and if found and within the time-to-live interval, returns status. If 
certificate status is not present or outsid e the time-to-live interval then the CSS 
retrieves status by first requesting connection information from its configuration 
store. The CSS then establishes a communications session with certificate 
status reporting component identified in its configuration store. The CSS 
composes a certificate status request as per the method contained in CSS 
configuration store, and the CSS retrieves certificate status from the certificate 
status reporting component and closes session with component. The CSS adds 
at least the certificate's ID. certificate status and time-to-live to its cache and 
returns certificate status to the requesting system or TCU. 

The certificate status reporting may be based on a CRL and processing of 

the CRL. According to the issuing CA's publication schedule, the CSS retrieves 
the CRL from the certificate status reporting component listed in the CSS 
configuration store. The CSS clears its cache memory associated with the 
issuing CA. parses certificate status from the CRL. and places the certificate 
status into its cache associated with the issuing CA. Upon notification bv an 
issuing CA that a "CRL is available, the CSS mav retrieve the "CRL from the 
certificate status reporting component listed in the CSS configuration store- 
Where it is required by standards that the "CRL is a complete CRL, then the CSS 
clears the cache associated with the issuing CA. parses the CRL. and places the 
certificate status and related information into the cache associated with Issuing 
CA. Where the "CRL contains only changes occurring after publication of a full 
CRL the CSS parses certificate status from "the CRL and places certificate 
status and related information into the cache associated with issuing CA 

Using a CSS to obtain certificate status that allows a user, system or TCU 
to use a single means for obtaining certificate stat us can include the steps of 
querying the CSS for the status of an authentication certificate present in a 



signature block on an information object, where the status auerv mav use a 
single means (e.g.. OCSPV translating the status query to a form required bv the 
issuing CA. and retrieving and/or reporting certificate status. If certificate status 
is revoked, the signature block is not used and remedy is reguired: if the digital 
signature verifies and certificate status is valid the signature block is added to 
the electronic original information object. 

The TCU can query the CSS to validate a signer's authentication 
certificate status by locating and reporting certificate status if the status is present 
and current in the CSS cache/data-store, and getting type and means for 
retrieving certificate status from the CSS configuration store. If the particular 
certificate status method is a CRL and the specified certificate's status is not 
found in the issuing CA cache in the CSS, then the CSS reports the certificate 
status as valid. If the certificate status method is not a CRL. then the CSS 

composes a certificate status request as per the method contained in CSS 
configuration store, and establishes appropriate communications with the issuing 
CA. The CSS retrieves certificate status from the status reporting component 
using the identified certificate status checking method and closes 
communications session. The CSS parses or interprets the retrieved certificate 
status, associates a time-to-live value e qual to the period sp ecified by status type 
as stated in the CSS policy, and adds at least the certificate's ID. status, and 
time-to-live values to issuing CA's certificate status cache. The CSS then returns 
certificate status to requesting system. 

A method for enrolling users in a system or TCU where certificate are 
issued bv an approved issuing CA that is known to a CSS includes vetting the 
user using established membership procedures and criteria, entering user 
enrollment information that has also been signed by an approved organization 
sponsor, and creating and sending a certificate reguest to the identified issuing 
CA. The user's authentication certificate is retrieved, issued, and placed on a 
token for delivery. Digital signature, digital signature verification and the CSS 
certificate status check are performed to ensure that public-kev pair generation 

and certificate issuance process were completed correctly. The user is required 



to sign the user acceptance agreement that commits the user to give the same 
weight to use of their digital signature as thev give to use of his or its hand written 
signature, the token is delivered to the user and the user's system or TCU 
account is activated. 

A method of enrolling users in a system or TCU where the user already 
has a certificate issued by a CA that is not previously known to a CSS can 
include querying the user's token for the user's authentication certificate and 
obtaining issuer information, and querying the CSS knowledge base to see if the 
issuing CA is contained therein. If not, the industry or organization policy 
administr ator is contacted to determine whether or not the iss uing CA meets the 
system rules for CA inclusion. Where the issuing CA is deemed "not authorized". 
registration terminates, and where the issuing CA is deemed "authorized". 

enrollment proceeds as described above. 

A portion of a user's authentication certificate contents mav be used to 
bind the certificate to a user's account by, after approving user for access to 
system or TCU. entering user enrollment information, inserting the user's token, 
that holds their authentication certificate, into a local token reader, retrieving and 
displaying the certificate contents, having the user affirm that the contents are 
correct, and adding selected fields to the system or TCU user enrollment data 
that is extracted from the certificate, such as certificate ID. issuing CA. a subset 
of the user's distinguished name or other identification information conveyed in 
certificate extensions (e.g.. subjectAltNamel The extracted data mav be 
specified in the system or TCU policy so that extraction and data entry mav be 
automated. 

A method whereby a submitter of an information object vouches for the 
authenticity of a submitted information object includes the step of affixing the 
submitter's signature block to an information object and/or wrapper and 
forwarding it to a system or TCU. If signature block validation fails, the TCU 
reouests retransmission or remedy and if signature block validation succeeds. 
the TCU then checks that the identity of the submitter matches that of the initiator 
of communication session, rejecting the submission if the initiator and submitter 



are different. If all checks succeed, the TCU adds its signature block to the 
submission, creating an electronic original information object 

A method in a CSS of maintaining accurate and timely certificate status for 
real-time certificate status reporting means that employ a time-to-live data 
element includes these steps. If a CRL status method is used then the CSS 
reports status. If certificate status is in cache and the time-to-live data element is 

not exceeded, then the C$s reports status. If the time-to-live data element is 
exceeded, the CSS clears the certificate status entry from the issuing CA cache. 
If status is retrieved using a real-time certificate status reporting means (e.g.. 
OCSP. LDAP query etc \ and status is not in cache, certificate status is 
requested, retrieved and reported. The CSS then adds at least the certificate's 
ID. certificate status and time-to-live to its cache and returns certificate status to 
the requesting system or TCU. 

A certificate status use-counter data element mav be added to a 

certificate's status entry in the CSS's issuing CA cache, and the status use- 
counter can be incremented or decremented every time a certificate's status is 
checked. If the status use-counter passes a threshold set by CSS policy, then 

the certificate status mav be reported but the CSS then clears the certificate 
status entry from the issuing CA cache. If the CSS-returned certificate status is 
invalid or revoked, then the system or T CU loos and/or reports the error to the 
submitter and/or transaction owner, and the reouested action is disallowed and 
remedy sought. Otherwise, the digital signature is deemed valid and the 
reouested action is allowed. A certificate status last-accessed data element mav 
be added and used in conjunction with the use-counter to determine the activity 
level of the certificates' status. 

A background process can cause the CSS to automatically retrieve 
updated certificate status and establish new time-to-live and use-counter data 
elements when a criterion in the CSS policy is met This pre-fetch mav he 
enabled to shorten the average time between system or TCU certificate status 
request and CSS response. 



If a request is made to the CSS to retrieve certificate status for a new 
certificate and the issuing CA cache has reached its allocated buffer size limit, 
the certificate status last-accessed data element mav be added to the certificate's 
status entry in the CSS's issuing CA cache. The CSS searches the issuing CA 
cache for th e latest-accessed data element for the oldest date (least-freguentlv- 
used^ and clears that entry. The CS S then retrieves the reouested certificates 
status places it in the freed location in the issuing CA cache and reports the 
status to the system or TCU which acts according to policy. 

A method of status checking in a distributed CSS includes coordinating 
between CSSs whenever a new issuing CA is introduced, estab lishing entries in 
all CSS knowledge bases if another CSS ha s primary responsibility for querying 
an issuing CA. guerving other CSSs instead of an issuing CA to reduce 
communications between the CSS and issuing CAs. synchronizing and caching 
certificate statuses locally if multiple local systems have a heavy concentration of 
certificate status requests against an issuing CA. and sharing or transferring the 
querying responsibility if another CSS has heavier activity with a given issuing 
CA than the original primary CSS. 

Excluding a set of users associated with an issuing CA bv changing the 
issuing CA reference in a CSS knowledge base to "not approved" can be done 
bv reouesting that approval for the issuing CA he withdrawn, reviewing the 
reguest on merit and determining what if anv action is needed, and if it is 
determined that for any reason the issuing CA should be disabled, then changing 
the issuing CA's status in the CSS knowledge base to "not approved". Any 
subseouent reouest for status of a certificate issued bv a CA listed as "not 
approved" results in the CSS returning a failed status. 

A method of re-enablina a set of users disabled bv previously setting an 
issuing CA reference to "not approved!" can be done by requesting that approval 
be granted for re-enabling the issuing CA. reviewing the request on merit and 
determining what if anv action is needed, and if it is determined that the issuing 
CA should be re-enabled, then changing the issuing CA's status in a CSS 



knowledge base to "approved". The CSS processes certificate status requests 
for reinstated issuing CAs as it would anv other "approved" CA. 

Communication with status reporting components can be established bv 
creating a modular and reusable apparatus for each certificate status protocol 
used to locate reouest and retrieve such information, using a version of the 
apparatus that is compatible with all CAs and resoonders that understand a 
particular certificate status protocol, and having a version of the apparatus for 
each status reporting protocol that is in use. The apparatus is designed so that it 
is easily adaptable to support future certificate status reporting protocols. 

Executing a transaction in which the submitter is a first TCU and the 
submission is to transfer custody of one or more electronic originals to a second 
TCU can include having the owner of the transaction instruct the first TCU to 
transfer custody of one or more electronic original documents to a second TCU. 
The owner of the transaction instructs the second TCU to transfer custody of one 
or more electronic original documents, and the owner provides the first TCU with 
a manifest that identifies which electronic originals are to be transferred to the 
second TCU. The first TCU establishes communications with the second TCU 
and identifies the p urpose of its actions to the second TCU. The first TCU or 
owner mav transmit the manifest to the second TCU so that it is able to 
determine when the transfer of custody has been completed. The first TCU 
transfers each identified electronic original to the second TCU. which uses the 
CSS to ensure that the first TCU's digital signature on each transferred electronic 
original is valid and that the electronic originals are unaltered. If anv of the first 
TCU's digital signatures are invalid, then the second TCU notifies the first TCU 

and seeKs remedy (e.g.. asks the first TCU to resign using current authentication 
certificate). If the first TCU is unable to comply, the second TCU loos the event 
and notifies the transaction owner that the requested transfer of custody has 
failed: otherwise the second TCU creates a new wra pper for each successfully 
transferred information object, adding a date-time stamp and its signature block. 
The second TCU notifies the first TCU of e ach successful transfer and upon 
completion, the first TCU mav at the discretion of the owner either mark and 



retain copies in such a manner that thev cannot be construed to be an original or 
mav destroy all conies that exist of the transferred information objects The 

process js repeated until all identified electronic originals are transferred. In this 

wav. the second TCU becomes the custodian for the transferred records that are 
the authoritative copies. The second TCU mav append a reliable date and time, 
digitally sign, wrap and store the manifest to make it an independent element of 
the trail-of-custodv. 

In executing a transaction, the owner's instruction may also state that a 
transfer of ownership takes place, and transfer of ownership documentation mav 
be Placed in either the first or second TCU. The responsible TCU validates the 

authenticity of the transfer of ownership documents by verifying all digital 

signature s, certificate validity periods, and using the CSS to check certificate 
status. The TCU then appends reliable date and time, and digitally signs, wraps 
and stores these now electronic original information objects, which are added to 
the manifest. Where these electronic originals are placed in the first TCU. 
transfer-of-ownership is implemented prior to transfer-of-custodv. and the 
initiating manifest becomes part of the trail-of-ownershio. 

Some of the transferred records mav be simple electronic information 
objects and not iust electronic originals The CSS mav use anv appropriate 
certificate status protocol to communicate with a system or TCU 

This invention can be embodied in many different forms without departing 
from its essential character, and thus the embodiments described above should 
be considered illustrative, not restrictive, in all respects. It is emphasized that the 
terms "comprises" and "comprising", as used in this description and the following 
claims, are meant as specifying the presence of stated features without 
precluding the presence of one or more other features. The intended scope of 
the invention is set forth bv the following claims, rather than the preceding 
description, and all variations that fall within the scope of the claims are intended 



